Various abbreviations are used in the present specification. These are listed and explained towards the end of the description.
Referring to FIG. 1, 3G video telephony of today supports call scenarios both between two mobile clients as well as between a 3G mobile 1 and an IP client 2. Video telephony services supported include interactive calls, streaming portals, video mail and multi-party calls.
The communication protocol used is the 3G-324M standard, which is an adaptation of the ITU-T H.324 standard (Terminal for low bit rate multimedia communication) to enable 3G conversational multimedia services over existing infrastructures of circuit switched (CS) networks. The 3G-324M architecture is defined by 3GPP in the 3G TS 26.111 standard.
The architecture defines audio and video codecs supported, together with the control signalling protocol (H.245) used to establish the multimedia communication. The control signalling is multiplexed together with the audio and video media using the H.223 multiplexing protocol.
The interworking functionality between the CS and the IP domain is handled by a CS-IP gateway 3. The CS-IP gateway 3 may be implemented using the H.248 architecture, where control signalling is handled by a Media Gateway Control Function (MGCF) 4 and media by a Media Gateway (MG) 5. CS endpoint 1 communicates with CS-IP gateway 3 via a RAN 6.
The control signalling used in the IP domain may be SIP, H.323 or RTSP, and media may be transported using the RTP protocol.
It has been appreciated that 3G video telephony services may suffer from having long call setup times due to the fact that the H.245 call establishment procedure results in significant signalling between the endpoints such as 1 and 2.
A recent update to the ITU-T H.324 standard is the introduction of Annex K, which describes an optional procedure named MONA “Media oriented negotiation acceleration procedure” comprising three complementary methods (or protocols) for significantly reducing delay in H.324 call setup. The methods are:                A fast channel setup mechanism, MPC “Media Preconfigured Channel”. This mechanism does not wait for capability exchange (i.e. the end points do not exchange information with each other as regards their capabilities) but requires a fallback if the initial media transmission attempts do not comply with the capability of the remote end when this information is available.        A flexible accelerated channel setup method, SPC “Signalling Preconfigured Channel” that depends on an initial exchange of preferences and the execution of a common inference algorithm.        An accelerated H.245 setup method, ACP “Accelerated H.245 procedures” as a simple and reasonably fast technique in cases where the other two methods are not suitable.        
Interoperation with legacy terminals not supporting MONA is also preserved across the procedures.
Annex K has defined the following MONA terminal classes to indicate which of the three methods a specific terminal implementation supports:                Class I: SPC+MPC+ACP        Class II: MPC+ACP        Class III: SPC+ACP        
FIG. 2 shows features of the 3G-324M standard including the MONA functionality.
It has been considered to introduce MONA support in the CS-IP interworking gateway 3 (MGCF 4 and MG 5) since it would be desirable to reduce call setup times for CS-IP multimedia calls and also to minimize signalling between the MGCF 4 and the MG 5 as a result of the reduced number of messages exchanged between MONA capable terminals.
A main focus of the present invention is CS-IP interworking when using any of the MONA mechanisms MPC, SPC or ACP on the CS side (i.e. if endpoint 1 is a MONA Class I, II or III terminal). A brief overview of the MONA procedure as specified in Annex K is provided below. A more detailed description can be found at ITU-T recommendation H.324 Annex K, which is hereby incorporated by reference.
If a terminal supports the MPC mechanism, then this mechanism may be used on the CS side. According to the MPC mechanism, once the CS bearer is established, the CS terminal starts sending preference messages including MPC codec preference per direction. The CS terminal may also start sending media on any of the preconfigured MPC channels before receiving any information of the MPC capability of the remote terminal. In case the remote terminal supports MPC and the codec preferred by the CS terminal, the channel is successfully established.
If a terminal supports the SPC mechanism, then this mechanism may be used on the CS side. According to this mechanism, once the CS bearer is established, the CS terminal sends its MOS (Media Oriented Setup) Request using the SPC (see FIG. 3). The MOS Request transmissions should be repeated until a MOS requestAck is detected, or one of the fallback conditions is fulfilled.
When a MOS Request is detected and decoded successfully from the MOS SPC, the terminal accepts it by beginning the transmission and processing of media data. MOS requestAck shall be sent on receiving every MOS Request.
If MOS is completed successfully, opened logical channels operate immediately, as shown in FIG. 3.
MONA Fallback is specified in K.7.2 of Annex K. The following additional conditions shall also initiate a fallback from MOS:                A normal H.245 TerminalCapabilitySet message with empty genericControlCapability containing MOS OID after completion of the MOS procedure.        A terminal does not detect a valid MOS request, or does not accept the ICM, within a multiple of the network round trip delay (RTD) period, for example within three RTDs.        
An overview over the ACP mechanism is not provided here as one skilled in the art will be familiar with this.
A main objective for a CS-IP interworking function 3 supporting MONA is to facilitate end-to-end codec negotiation between the endpoints 1, 2, in order to achieve best possible media quality. Supporting end-to-end codec negotiation will also minimize utilization of expensive transcoding resources in the interworking gateway 3.
It has been appreciated that call signalling interworking between a MONA and an IP endpoint (i.e. SIP, H.323 or RTSP endpoint) via a CS-IP gateway is problematic for calls originated by the CS terminal using both MPC and SPC. Problems arise in the MPC case since media channels are opened immediately once media is received on a supported preconfigured channel. Problems arise in the SPC case since the SPC procedure has strict timing constraints.
The problem encountered in the SPC case will now be explained in more detail. As stated in H.324 Annex K, a SPC capable endpoint shall send its MOS request once the CS bearer is established. This is especially challenging for CS→IP calls if end-to-end codec negotiation is to take place.
FIGS. 4 and 6 show two CS→IP call sequences showing two alternative signalling interworking examples for how a call between a MONA SPC endpoint (such as 1) and a SIP endpoint (such as 2) can be established according to the prior art, and FIG. 5 (which is similar to FIG. 4) shows a CS→IP call sequence showing a signalling interworking example for how a call between a MONA MPC endpoint (such as 1) and a SIP endpoint (such as 2) can be established according to the prior art.
In the CS to IP call establishment example sequences of FIGS. 4 and 5 MONA SPC negotiation and MONA MPC negotiation is finished without knowledge of the codec capability of the SIP endpoint, i.e. the codec capability of the SIP endpoint is not taken into account during the MONA SPC or MPC, negotiation, which takes place entirely on the CS side (steps 4. to 7. in FIG. 4; steps 4. and 5. in FIG. 5). The negotiated codec on the CS side is used as preference in the SIP negotiation (steps 8. and 9.) but in case this codec is not supported by the SIP endpoint, CS-IP gateway transcoding will be required.
The signalling interworking example shown in FIG. 6 includes some form of end-to-end codec negotiation since SIP negotiation is initiated before the CS bearer is established. The codecs preferred by the SIP endpoint (communicated in step 9. in FIG. 6) are then used as preference in step 4. of MONA MPC/SPC negotiation (steps 4. to 7.). In case the MONA endpoint does not accept the selected codec on the IP side, a SIP re-negotiation has to be initiated (steps 8a. and 9a), possibly resulting in that transcoding resources within the CS-IP gateway have to be deployed. Only SPC negotiation is shown in FIG. 6, i.e. the interworking gateway of this example acts as a MONA class III terminal. It will be clear to one skilled in the art how this example is to be adapted for the purpose of MPC negotiation.